Creating a model or diagram is often the first step when designing a process or deploying a system. A model can be defined as a complete specification of a problem or solution domain from a particular perspective. Ultimately, a model is a logical concept that can be expressed physically as a drawing, for example on a whiteboard or in a modeling tool. Exemplary models include business analysis models, class diagram models, use-case models, design models, deployment models, data models, etc. A model can either be constructed in a formal manner, i.e., with semantic details included, or in an informal manner, i.e., without semantic details. More specifically, as “semantic” pertains to the different meanings of words or symbols, “semantic details” added to a model identify or define concepts in a model. Typically, an initial model or diagram is constructed in an informal manner without tying specific definitions to the model (referred to herein as a “semantic-less model”). This allows the creator to get an idea down on paper while not having to worry about the specific details of his design. A semantic-less model is composed of notational elements. A notational element is an informal element that is used to visually depict a component of a semantic-less model but adds no semantic details. For example, a notational element might be a rectangle drawn as a component of a model. The rectangle might represent that a function or process should take place here, but may not specifically define what the function or process is or how it operates. Several graphical editors, such as Microsoft Visio and PowerPoint, allow users to create models and diagrams without being required to allocate semantic meaning (e.g., defining the process represented by the box in the above example) to each notational element (referred to herein as a “semantic-less editor”). However, without semantics, the model created (or the logical concept defined by the model) can't be validated or used to automatically generate other content. A model with all the logical components clearly defined may be referred to as a “formal” or “semantic” model.
If a user desires to make a formal model or diagram, a graphical semantic editor, such as IBM Rational Rose and PowerDesigner, is used. A model created by a graphical semantic editor is composed of semantic elements. Semantic elements provide the semantic details previously discussed and may be classes, activities, relationships, specific machines, or any descriptive information, and may be depicted as graphically illustrated components of the model. For example, in a system deployment model describing a website, the components would include hardware components such as a web server and an application server, and software components such as a web application and a database. Each of these components are semantic elements of the deployment diagram and may be displayed as an image recognized by the graphical semantic editor as a known component. Taking the example from above where an informal notational element was a rectangle depicting some function or process that should be included; the corresponding semantic element might be a rectangle with a name of a specific and recognizable function. Alternatively, the corresponding semantic element could be any image recognized by the semantic editor as representative of the specific function.
The relationship between various semantic elements, referred to herein as a “semantic relationship”, can also be visually depicted. For example, if the web server hosts the web application, the two corresponding semantic elements would have a semantic relationship which may be depicted by the semantic element representing the web application being shown contained within the semantic element representing the web server. A semantic element may, in some embodiments, have a number of semantic properties providing further details. For example, for the semantic element representing a web server, the amount of memory and the speed of the server processor are possible semantic properties of the web server semantic element that can be included in the semantic model by a user if a higher degree of specificity is desired.
Creating semantic models can be more difficult than creating semantic-less models because they force the user to be continually aware of the details of their model. Often, semantic editors force users to pick the exact semantic element and its relationship to another semantic element before it can be added to the model. With regard to the example above, when building a semantic model, the user would need to not only identify the hardware and software components as specific semantic elements (e.g., the web server and the web application), but in addition, the user would need to identify a specific semantic relationship (e.g., the server hosting the application) before the semantic model would be complete.
For most graphical semantic editors, Unified Modeling Language (UML) has become a standard visual modeling language for software specification and design. UML is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software intensive system under development. In other words, for most semantic editors, semantic elements and their corresponding relationships and properties are presented in terms of UML. This can present problems for users wishing to convert a semantic-less model into a semantic model.
A graphical semantic editor may support conversion between semantic and semantic-less models. These hybrid editors typically provide the user with a tool palette of a set number of notational elements or shapes that can be added to a visual depiction of an informal or semantic-less model. In this manner, a user is not forced to sketch each component of a semantic-less model manually. These notational elements or shapes provided by hybrid editors are referred to herein as “sketch shapes”. After the informal model is composed, the user is then given the option of converting the entire semantic-less model to a semantic model or converting each individual semantic-less component into a semantic element by filling in the semantic details required to create each semantic element and/or semantic relationship. The sketch shapes can also be given sketch shape names and sketch shape descriptions at the user's discretion, which serve as informal details for each sketch shape. A sketch shape name can be used to identify a specific matching semantic element. A sketch shape name can also be used to identify a category of sketch shapes which correlate to a specific semantic element or category of semantic elements. Additionally, a sketch shape description can be used to identify a category of descriptions which correlate to one or more semantic properties. Once the semantic model is created, the semantic editor stores the semantic-less model and may even create a link to the semantic-less model within the semantic model. Therefore, the user can go back and forth between the semantic-less model and the semantic model at any time.